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Overview 


Organizational  Structure 


Primarily  Software 

Primarily  System  Engineering 
Primarily  Services 


lOO"^  personnel  within  the  organization 


Journey  Overview 
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Transitioning  from  CMMI  v1 .2  to  v1 .3 


Effort  expanded  to  Services  (CM,  QA,  MA, 
Meetings,  Peer  Review,  Management  Reviews) 


Effort  expanded  to  Systems 
Engineering 


OSP  Streamlined  using  AFS021  principles.  Support 
Tools  enhanced 


Defect  Prevention  &  TCM  Processes 
established 


SCAMPI  A  CMMI  Maturity 
Level  (ML)  5  Appraisal 
Goal:  ML3 


PSO  and  TWGs  established 


Benchmark  SCAMPI  A  CMMI 
Level  3  Appraisal 


Benchmark  Appraisal  to 
establish  CMMI  transition  plan 


CMM  Level  5 
achieved 


Quick  Look  -  Level  3 
well  established,  high 
probability  of  Level  5 


Return  on  Investment  Demonstrated 

•  Higher  Productivity  (46%  increase) 

•  Improved  Quaiity  (13%  less  corrective  work) 

•  Better  Estimation  (56%  improvement  in 
achieving  or  exceeding  organizational  goals) 
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The  Approach 


•  Assess  CMMI®  Model  Delta 

•  Expand  Model  Application 

•  Address  the  Culture  Changes 

•  Update  Processes/Tools 

•  Measure  Performance  Quantitatively 


Assess  CMMI®  Model  Delta 


•  Raised  the  bar: 

-  Added  a  Measurement  and  Analysis  Process  Area  (PA)  at  Maturity 
Level  (ML)  2 

-  Restructured  7  PAs  into  11  PAs  at  ML  3 

-  Renamed  4  PAs  at  MLs  4  and  5  to  provide  more  focus  on  the 
quantitative  nature  of  a  high  maturity  organization 

•  Replaced  common  features  with  generic  goals 
and  generic  practices 

•  Expanded  software  scope  to  include  systems 
engineering,  services  as  well  as  integrated 
process  and  product  development 
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Expand  Model  Application 


•Defined  strategic  business  goals 

-  Quality 

-  Cost 

-  Timeliness 

-  Customer  Satisfaction 

•  Integrated  established  best  practices 

-  Systems  and  Software  Technology  Conference  (SSTC) 

-  Software  Engineering  Process  Group  (SEPG)  Conference 

•  Tailored/re-used  proven  processes 

-  Change  project  to  work  or  tasks 

-  Change  software  to  standard 


Expand  Model  Application 


•  Communicated  the  Philosophy 

-  Built  a  flexible  process  for  adaptation 

-  Sought  common  solutions  -  do  not  document  each 
methodology  being  utilized  (i.e.  software  process,  systems 
engineering  process) 

•  Established  Process  Improvement  Goals 

-  Identified  the  initial  environment/scope 

-  Defined  the  target  environment/scope 

-  Updated  the  interim  environment  to  track  the  progress  of 
migrating  from  the  initial  to  the  target  environment 
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Address  the  Culture  Changes 


•  Developed  a  Transition  Plan 

-  Systems  Engineering 

-  Services  (Systems  Administration) 

•  Involved  affected  personnel 

-  Communicated  often 

-  Coordinated  with  the  ''E.F.  Hutton"  of  the  team  to  understand  how 
to  add  value  and  mentor  to  them  to  serve  as  the  Process  Champion 

-  Identified  aspects  of  the  model  that  would  add  value  to  the  day-to- 
day  tasks 


Remember  when  we  first  started  our  journey  -  "we  are  unique"  was  said 

as  much  as  "it  depends" 


Update  Processes/Tools 


•  Distributed  Process  Ownership 

-  Tailored  processes  to  meet  business  needs  for  systems  engineering 
and  services 

-  Empowered  software  and  system  engineers  to  work  collaboratively 
to  define,  implement,  manage  and  optimize  process  improvements 

-  Encouraged  identification  of  data-analysis  based  improvements 

-  Mandated  team  members  follow  the  process 

•  Instilled  a  Collaborative  Environment 

-  Updated  tools  to  change  terminology 

-  Shared  lessons  learned  from  software  development  and 
communicate  their  applicability  to  systems  engineering  and 
services 

-  Established  User  Group  Meetings  in  a  question/answer  forum 

-  Setup  Quality  Assurance  support  for  each  systems  engineering  and 
services  task  to  maximize  consistency 


Update  Processes/Tools 


•  Identified  Role-Based  Training  Requirements 

-  Trained  core  individuals  defining  the  processes  in  the  model 
versus  the  entire  organization 

—  Trained  only  the  applicable  processes  when  expanding  the  scope 

-  Scheduled  just  in  time  training  based  upon  planned  process 
utilization 


Measure  Performance  Quantitatively 


•  Created  a  Data  Repository 

-  Centralized  project  data  access  and  storage 

-  Reduced  redundant  data  entry  for  daily  tasks 

-  Eliminated  the  "Big  Honkin"  binder 

-  Automated  quantitative  analysis  tasks 


•  Identified  Measures 

-  Created  metrics  based  on  strategic  goal  measures  at  the 
organization,  management  and  project  levels 

-  Initially  focused  on  breadth  not  depth  -  depth  evolved  based  on 
the  analysis  results 
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Measure  Performance  Quantitatively 


•  Tracked  Performance 

-  Defined  quantitative  goals  by  which  to  measure  performance 

-  Identified  frequency  for  reporting  performance/status  against  goals 

•  Reported  Performance 

-  Reported  metrics  for  systems  engineering  early  in  the  transition 
phase 

-  Highlighted  differences  in  systems  engineering  execution  of  the 
processes  to  identify  best  practices  and  engage  the  systems 
engineers  in  the  process  effectiveness 


Initial  Perspective:  Do  not  wait  until  data  is  needed  to  collect  it  -  it  will  be  too  late 

Current  Perspective:  Do  not  require  data  collection  if  an  information  need  is  not 
being  addressed 


Challenges 


•  73%  of  the  PAs  were  common  between  CMM®  vl.l  and 
CMMI  vl.2® 


•  30%  of  the  processes  were  perceived  to  be  common 
between  Software  and  Systems  Engineering  personnel 

•  90%  of  the  organization's  processes  were  common 
between  Software,  Systems  Engineering  and  Services 
once  expansion  was  completed 
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Lessons  Learned 


•  Most  effort  expended  in  communication  with  the 
Systems  Engineering  and  Services  personnel  to  move 
the  30%  perception  to  the  90%  reality 


•  Data  is  the  best  tool  for  communication  as  it  shows  the 
capability  and  stability  of  the  processes  being  used 
within  each  discipline 
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Lessons  Learned 


•  Not  formally  applying  integrated  process  and  product 
development  (IPPD)  practices  limited  the  success  of  our 
journey  -  collaboration  is  critical  to  the  transition 


•  Sharing  past  experiences  and  techniques  between 
software  ,  systems  engineering  and  services  personnel 
proved  very  effective 
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Lessons  Learned 


•  Metric  data  for  Services  required  a  different  context 
than  Software  or  Systems  Engineering  -  concept  is  the 
same  but  terminology  is  VERY  different 


•  Change  Agents,  Process  Champions  and  Management 

must  create  an  environment  for  cultural  change 

-  Technology  change  is  more  readily  accepted  than  process 
change 
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Lessons  Learned 


•  Setting  a  planned,  strategic  expansion  is  key 

-  Software  set  a  strong  foundation 

—  Systems  Engineering  leveraged  off  that  foundation  without  a 
significant  impact 

-  Services  practice  the  activities,  but  without  the  formality 
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Summary 


•  Setting  expectations  to  eliminate  all  resistance  is 
unreasonable  -  effective  process  improvement 
program  uses  resistance  to  improve  processes 


•  Addressing  metrics  in  terms  of  breadth  versus  depth 
provides  increased  flexibility  in  data  analysis  when 
initial  results  vary  from  expectations 

•  Involving  engineers  early  in  the  journey  accelerates  the 
process  definition  and  cultural  acceptance 
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Questions? 


“Effective  change  demands 
continual,  forward  thinking 
with  a  desire  to  add  value.  If 
value  is  not  added  by  the 
change,  we  must  be  willing 
to  abandon  it!” 

by  Kathy  Reid 
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